Statement of the Technical Field
The present invention relates to the field of application component distribution, and more particularly to the target platform neutral management of application component requirements during the installation of an application component.
Description of the Related Art
Though often overlooked, application installation is a prerequisite to interacting with a software application. Specifically, in most circumstances, an application can be properly executed only subsequent to the completion of a successful installation process. At the minimum, a typical software application installation requires a transfer of files to the file structure of a computing system, and the configuration of the computing system to particularly interact with the software application. Ordinarily, the configuration of the computing system includes the addition or modification of registry settings, the addition or modification of entries to one or more initialization files, or both.
In the context of an application installation meant to upgrade the components of an application, oftentimes, simply replacing application out-dated versions of application components with newer versions of components will not alone suffice as a complete application upgrade. Rather, in an era of code re-use, shared libraries, and interdependent program objects, replacing a single application component can have a dramatic effect upon other separate, but independent applications. Common disastrous consequences include altered and now incompatible application programming interfaces (APIs), re-positioned application objects, and removed application objects. In all cases, an application dependency can be broken simply by upgrading the application components of another, unrelated application.
Whereas application component upgrades can be problematic generally, in an autonomic system, the problem can be particularly acute. For the uninitiated, autonomic computing systems self-regulate, self-repair and respond to changing conditions, without requiring any conscious effort on the part of the computing system operator. To that end, the computing system itself can bear the responsibility of coping with its own complexity. The crux of autonomic computing relates to eight principal characteristics:    I. The system must “know itself” and include those system components which also possess a system identify.    II. The system must be able to configure and reconfigure itself under varying and unpredictable conditions.    III. The system must never settle for the status quo and the system must always look for ways to optimize its workings.    IV. The system must be self-healing and capable of recovering from routine and extraordinary events that might cause some of its parts to malfunction.    V. The system must be an expert in self-protection.    VI. The system must know its environment and the context surrounding its activity, and act accordingly.    VII. The system must adhere to open standards.    VIII. The system must anticipate the optimized resources needed while keeping its complexity hidden from the user.
Thus, in keeping with the principles of autonomic computing, the installation of application components must not only account for the seamless installation and configuration of the application components, but also the impact of the installation upon existing applications in the target platform. Moreover, it can be important that dependencies required for the nominal operation of the application components exist within the target platform, or can be accessed from the target platform. Finally, it can be critical that the infrastructure provided by the target platform, including its computing resources, meets the resource requirements of the application components. Hence , it will be of paramount concern to the autonomic system that the target platform itself will not become “broken” in consequence of the installation of the application components.
Presently, several application upgrade strategies exist. One such well-known strategy includes the venerable “ReadMe” file. In this strategy, software developers provide a list, typically as standard prose, of components in the application which are to be installed, the required pre-requisite components and any resource requirements to be provided by the target platform. Subsequently, during installation, an application administrator can peruse the contents of the list to determine the nature of the component installation. As it will be recognized by one skilled in the art, however, the creation and use of a conventional ReadMe file can be both tedious and unreliable.
It will also be well understood by those skilled artisans that automated methods exist at least to remediate the tedium associated with the conventional ReadMe file. Specifically, various programming tools have been developed through which application component dependencies can be identified among system elements. Prior to any installation effort, the programming tool can be executed so as to determine the risk of undertaking the application installation. Still, this process lacks the granularity necessary to definitively assess the changing nature of dependencies. Moreover, modern automated methods are target platform specific. As a result, modern automated methods remain product level solutions which are ill-suited for the “write once run anywhere” nature of modern enterprise computing.